Materialized Query Table Matching With Query Expansion

ABSTRACT

Methods, apparatuses, and computer program products for materialized query table matching are provided that include receiving a database query, retrieving a materialized query table (MQT) from data storage accessible to a database management system, selecting a join in the materialized query table between a table that is not invoked by the query and a table that is invoked in the query, determining whether the selected join is lossless, and expanding the query to include the lossless join if the selected join is lossless, expanding the query to include the lossless join. Determining whether the selected join is lossless may be carried out by losslessly joining the table that is not invoked by the query to the query, and determining whether the lossless join to the query matches the selected join of the materialized query table.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application of and claims priorityfrom U.S. patent application Ser. No. 11/068,264, filed on Feb. 28,2005.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of the invention is data processing, or, more specifically,methods, systems, and products for materialized query table matching.

2. Description of Related Art

The development of the EDVAC computer system of 1948 is often cited asthe beginning of the computer era. Since that time, computer systemshave evolved into extremely complicated devices. Today's computers aremuch more sophisticated than early systems such as the EDVAC. The mostbasic requirements levied upon computer systems, however, remain littlechanged. A computer system's job is to access, manipulate, and storeinformation. Computer system designers are constantly striving toimprove the way in which a computer system can deal with information.

Information stored on a computer system is often organized in astructure called a database. A database is a grouping of relatedstructures called ‘tables,’ which in turn are organized in rows ofindividual data elements. The rows are often referred to as ‘records,’and the individual data elements are referred to as ‘fields.’ In thisspecification generally, therefore, an aggregation of fields is referredto as a ‘data structure’ or a ‘record,’ and an aggregation of records isreferred to as a ‘table.’ An aggregation of related tables is called a‘database.’

A computer program that supports access to information in a database istypically called a database management system or a ‘DBMS.’ A DBMS isresponsible for helping other computer programs access, manipulate, andsave information in a database. A DBMS typically supports access andmanagement tools to aid users, developers, and other programs inaccessing information in a database. One such tool is the structuredquery language, ‘SQL.’ SQL is query language for requesting informationfrom a database. Although there is a standard of the American NationalStandards Institute (‘ANSI’) for SQL, as a practical matter, mostversions of SQL tend to include many extensions. Here is an example of adatabase query expressed in SQL:

select * from stores, transactions where stores.location = “Minnesota”and stores.storeID = transactions.storeID

This SQL query accesses information in a database by selecting recordsfrom two tables of the database, one table named ‘stores’ and anothertable named ‘transactions.’ The records selected are those having value“Minnesota” in their store location fields and transactions for thestores in Minnesota. In retrieving the data for this SQL query, a SQLengine will retrieve records from the stores table and records from thetransaction table. Records that satisfy the query requirements then arecombined in a ‘join.’

To improve the performance of satisfying a query, many databases storethe results of previous queries or portions of the results of previousqueries and use the stored results to satisfy subsequent queries. Suchstored results for performance enhancement are called materialized querytables (‘MQT’). An MQT is a table whose definition is based on theresult of a query, and whose data is in the form of pre-computed resultsthat are taken from one or more tables.

An MQT does not have to contain the results of exactly the same query tobe useful in subsequent queries. A subsequent database query cansometimes be satisfied using an MQT that is similar to the query.Consider the following MQT and database query.

The MQT:

SELECT e.name empname, d.name deptname FROM employees e, departments dWHERE e.dept=d.idmay be used to satisfy the query:

SELECT e.name, d.name FROM employees e, departments d WHERE e.dept=d.idAND d.name=‘Engineering’by selecting records from the MQT such as:

SELECT empname, deptname FROM mqt WHERE deptname=‘Engineering’

In this example the query selects a subset of the results of the MQT.One situation where MQTs are useful therefore includes queries whoseresults represent a subset of the selected records of the MQT. In somecases, the extra records are a result of having tables joined in the MQTthat are not invoked in the query. One existing method of MQT matchinguseful in a situation where the MQT has one or more tables not invokedin the query is carried out by eliminating the extra table or tablesfrom the MQT using referential integrity reduction until the MQT has noextra tables that are not in the query.

Another way where MQTs could be useful in satisfying the queries mayinvolve expanding the query under certain circumstances to includetables that are joined in the MQT but are not in the query. Consider thefollowing MQT:

SELECT e.name empname, d.name deptname FROM employees e, departments dWHERE e.dept=d.id

And the following query:

SELECT e.name empname FROM employees e WHERE e.name LIKE ‘A%’

In this example, the MQT references the departments table, but thisquery does not. The MQT may in fact satisfy the query if joining to thedepartments table is a lossless join. The phrase ‘lossless join’ means ajoin between a first table and a second table that returns the samenumber of records as the first table. That is, a lossless join does notproduce ‘fan out,’ more records than the first joined table, or ‘fanin,’ less records than the first joined table. The use of the term‘first table’ and ‘second table’ is simply used to distinguish twotables. There is no order requirement between the first or second table.The lossless join may be lossless with respect to either table. In thisexample, if the join is lossless, then the join to the departments tablein the MQT merely widens the result set to include some departmentinformation. Such an MQT may be useful in materialized query tablematching if the query can be properly expanded to match the MQT.

SUMMARY OF THE INVENTION

Methods, apparatuses, and computer program products for materializedquery table matching are provided that include receiving a databasequery, retrieving a materialized query table from data storageaccessible to a database management system, selecting a join in thematerialized query table between a table that is not invoked by thequery and a table that is invoked in the query, determining whether theselected join is lossless, and expanding the query to include thelossless join if the selected join is lossless.

Determining whether the selected MQT join is lossless may be carried outby losslessly joining the table that is not invoked by the query to thequery, and determining whether the lossless join to the query matchesthe selected join of the materialized query table (MQT).

Losslessly joining the table that is not invoked by the query to thequery may be carried out by identifying a primary key in the table notinvoked by the query, identifying a foreign key in the table that isinvoked by the query, identifying the same foreign key in the query, andlosslessly joining the primary key of the table not invoked by the queryto the same foreign key in the query. Losslessly joining the primary keyof the table not invoked by the query to the same foreign key in thequery is carried out by creating a join predicate that results in alossless join between the primary key of the table not invoked by thequery and the same foreign key of the query. Materialized query tablematching according to embodiments of the present invention may alsoinclude creating a copy of the query and losslessly joining the primarykey to the same foreign key of the copy of the query.

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescriptions of exemplary embodiments of the invention as illustrated inthe accompanying drawings wherein like reference numbers generallyrepresent like parts of exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 sets forth a network diagram illustrating an exemplary system ofcomputers each of which may support a database capable of materializedquery table matching according to embodiments of the present invention.

FIG. 2 sets forth a block diagram of automated computing machinerycomprising a computer useful in materialized query table matchingaccording to embodiments of the present invention.

FIG. 3 sets forth a flow chart illustrating an exemplary method formaterialized query table matching according to embodiments of thepresent invention.

FIG. 4 sets forth a flow chart illustrating an exemplary method fordetermining whether a selected join in an MQT is lossless.

FIG. 5 sets forth a flow chart illustrating an exemplary method forlosslessly joining the table that is not invoked by the query to thequery.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS Materialized Query TableMatching

Exemplary methods, apparatuses, and computer program products formaterialized query table matching according to embodiments of thepresent invention are described with reference to the accompanyingdrawings, beginning with FIG. 1. FIG. 1 sets forth a network diagramillustrating an exemplary system of computers each of which may supporta database capable of materialized query table matching according toembodiments of the present invention. The system of FIG. 1 includes anumber of computers coupled for data communications to networks. Thesystem of FIG. 1 includes a server (106) coupled for data communicationsto a wide area network (‘WAN’) (101) through a wireline connection(119), a personal computer (108) coupled to the WAN (101) through awireline connection (120) and a PDA (113) coupled to the WAN (101)through a wireless connection (114). The system of FIG. 1 also includesa workstation (104) coupled to the WAN (101) through a wirelineconnection (122), a network enabled mobile phone (110) coupled to theWAN (101) through a wireless connection (116), a personal computer (102)coupled to the WAN (101) through a wireline connection (124), and alaptop (126) coupled to the WAN (101) through a wireless connection(118).

Each of the exemplary computers (113, 104, 110, 102, 108, 126, 106) ofFIG. 1 have installed upon them a database management system capable ofmaterialized query table matching according to embodiments of thepresent invention. Such database management systems operate generally byreceiving a database query, retrieving a materialized query table fromdata storage accessible to a database management system, selecting ajoin in the materialized query table between a table that is not invokedby the query and a table that is invoked in the query and determiningwhether the selected join is lossless. If the selected join is lossless,the database management system operates by expanding the query toinclude the lossless join. Database management systems operatingaccording to embodiments of the present invention repeatedly selectMQTs, select join from the MQTs, determine whether the selected join islossless, and expand the query if the join is lossless until the queryis expanded to match the MQT thereby advantageously providing a vehiclefor efficiently satisfying the query.

The term materialized query table or MQT is used in this specificationto mean any stored results of previous queries or portion of results ofprevious queries. MQTs may also be known as ‘automated summary tables’(‘AST’) or by other names as will occur to those of skill in the art andall such stored results are useful as MQTs according to embodiments ofthe present invention.

The phrase ‘lossless join’ means a join between a first table and asecond table that returns the same number of records as the first table.That is, a lossless join does not produce ‘fan out,’ more records thanthe first joined table, or ‘fan in,’ less records than the first joinedtable. The use of the term ‘first table’ and ‘second table’ is simplyused to distinguish two tables. There is no order requirement betweenthe first or second table. The lossless join may be lossless withrespect to either table.

The arrangement of servers and other devices making up the exemplarysystem illustrated in FIG. 1 are for explanation, not for limitation.Data processing systems useful according to various embodiments of thepresent invention may include additional servers, routers, otherdevices, and peer-to-peer architectures, not shown in FIG. 1, as willoccur to those of skill in the art. Networks in such data processingsystems may support many data communications protocols, including forexample TCP/IP, HTTP, WAP, HDTP, and others as will occur to those ofskill in the art. Various embodiments of the present invention may beimplemented on a variety of hardware platforms in addition to thoseillustrated in FIG. 1.

As mentioned above, materialized query table matching in accordance withthe present invention is generally implemented with computers, that is,with automated computing machinery. For further explanation, FIG. 2 setsforth a block diagram of automated computing machinery comprising acomputer (152) useful in materialized query table matching according toembodiments of the present invention. The computer (152) of FIG. 2includes at least one computer processor (156) or ‘CPU’ as well asrandom access memory (168) (“RAM”).

Stored in RAM (168) is database management system (106). The exemplarydatabase management system (106) of FIG. 2 is capable of materializedquery table matching according to the present invention. The exemplarydatabase management system (106) of FIG. 2 is capable of materializedquery table matching by receiving a database query, retrieving amaterialized query table from data storage accessible to a databasemanagement system, selecting a join in the materialized query tablebetween a table that is not invoked by the query and a table that isinvoked in the query, determining whether the selected join is lossless,and expanding the query to include the lossless join if the selectedjoin is lossless. The exemplary database management system (106) of FIG.2 repeatedly selects MQTs, selects joins from the MQTs, determineswhether each selected join is lossless, and expands the query if thejoin is lossless until the query is expanded to match the MQT therebyadvantageously providing a vehicle for efficiently satisfying query.

Also stored in RAM (168) is an operating system (154). Operating systemsuseful in computers according to embodiments of the present inventioninclude Unix, Linux, Microsoft NT™, i5/OS, and many others as will occurto those of skill in the art. Operating system (154) and DBMS (106) areshown in RAM (168), but many components of such software typically arestored in non-volatile memory (166) also.

The computer (152) of FIG. 2 includes non-volatile computer memory (166)coupled through a system bus (160) to processor (156) and to othercomponents of the computer. Non-volatile computer memory (166) may beimplemented as a hard disk drive (170), optical disk drive (172),electrically erasable programmable read-only memory space (so-called‘EEPROM’ or ‘Flash’ memory) (174), RAM drives (not shown), or as anyother kind of computer memory as will occur to those of skill in theart.

The example computer of FIG. 2 includes one or more input/outputinterface adapters (178). Input/output interface adapters in computersimplement user-oriented input/output through, for example, softwaredrivers and computer hardware for controlling output to display devices(180) such as computer display screens, as well as user input from userinput devices (181) such as keyboards and mice.

The exemplary computer (152) of FIG. 2 includes a communications adapter(167) for implementing data communications (184) with other computers(182). Such data communications may be carried out through RS-232connections, through external buses such as USB, through datacommunications networks such as IP networks, and in other ways as willoccur to those of skill in the art. Communications adapters implementthe hardware level of data communications through which one computersends data communications to another computer, directly or through anetwork. Examples of communications adapters useful for determiningavailability of a destination according to embodiments of the presentinvention include modems for wired dial-up communications, Ethernet(IEEE 802.3) adapters for wired network communications, and 802.11badapters for wireless network communications.

For further explanation, FIG. 3 sets forth a flow chart illustrating anexemplary method for materialized query table matching according toembodiments of the present invention. The method of FIG. 3 includesreceiving (302) a database query (304). The query (304) of FIG. 3 may bea SQL query or any other database query as will occur to those of skillin the art.

The method of FIG. 3 also includes retrieving (306) a materialized querytable (308) from data storage accessible to a database managementsystem. As discussed above, the term materialized query table or MQT isused in this specification to mean any stored results of previousqueries or portion of results of previous queries. MQTs may also beknown as ‘automated summary tables’ (‘AST’) or by other names as willoccur to those of skill in the art and all such stored results areuseful as MQTs according to embodiments of the present invention.Retrieving (306) a materialized query table (308) from data storageaccording to the method of FIG. 3 may be carried out by retrieving anMQT at random from data storage, retrieving an MQT in an ordered mannerfrom data storage such as incrementally or algorithmically by MQT ID, orany other way of retrieving a MQT that will occur to those of skill inthe art.

The method of FIG. 3 also includes selecting (310) a join in thematerialized query table (308) between a table (314) that is not invokedby the query and a table (316) that is invoked in the query. Selecting(310) such a join (312) in the materialized query table (308) may becarried out by retrieving a join in the MQT and determining whether oneof the tables in the join is invoked in the query and whether the othertable in the join is not invoked in the query.

The method of FIG. 3 also includes determining (318) whether theselected join (312) is lossless. The phrase ‘lossless join’ means a joinbetween a first table and a second table that returns the same number ofrecords as the first table. That is, a lossless join does not produce‘fan out,’ more records than the first joined table, or ‘fan in,’ lessrecords than the first joined table. The use of the term ‘first table’and ‘second table’ is simply used to distinguish two tables. There is noorder requirement between the first or second table. The lossless joinmay be lossless with respect to either table. Determining (318) whetherthe selected join (312) is lossless may be carried out by losslesslyjoining the table that is not invoked by the query to the query tocreate a known lossless join and determining whether the lossless jointo the query matches the selected join of the materialized query tableas discussed in more detail with reference to FIGS. 4 and 5.

If the selected join (312) is lossless, the method of FIG. 3 alsoincludes expanding (320) the query (322) to include the lossless join.Expanding the query to include the lossless join is typically carriedout by including in the query the table (314) that was added to thequery to determine whether the MQT join was lossless. That is, expandingthe query is typically carried out by saving the known lossless joinadded to the query as part of the query. Creating the known losslessjoin included in the expanded query is discussed in more detail withreference to FIGS. 4 and 5.

If the selected join (312) is not lossless, then the MQT (308) is notavailable for MQT matching according to the method of FIG. 3 and the MQTis simply discarded. In some embodiments, another MQT may be selectedand the method of FIG. 3 may be repeated.

After expanding the query to include the lossless join, the method ofFIG. 3 continues by determining (324) whether all the joins in thematerialized query table have been selected and selecting (330) anotherjoin if all the joins in the materialized query table have not beenselected.

The method of FIG. 3 expands the query to include lossless joins foundin the MQT. For further explanation therefore, FIG. 4 sets forth a flowchart illustrating an exemplary method for determining (318) whether theselected join (312) is lossless. The method of FIG. 4 includeslosslessly joining (402) the table (314) that is not invoked by thequery to the query to create a known lossless join (404) and determining(406) whether the known lossless join (404) to the query (304) matchesthe selected join (312) of the materialized query table. If the knownlossless join (404) to the query (304) matches the selected join (312)of the materialized query table, then the selected join is determined tobe lossless. If the known lossless join (404) to the query (304) doesnot match the selected join (312) of the materialized query table, thenthe selected join is not determined to be lossless. In summary, themethod of FIG. 4 identifies that the selected join is lossless bycreating a known lossless join and then determining whether the selectedjoin matches the known lossless join.

Losslessly joining (402) the table (314) that is not invoked by thequery to the query to create a known lossless join (404) is carried outby creating a join predicate that results in a lossless join between theprimary key of the table not invoked by the query and the same foreignkey of the query. Constructing a join predicate such that one and onlyone record is returned for each record in the table in the query may becarried out through the use of referential integrity constraintsenforced on the DBMS. Referential integrity constraints are rules thatenforce required relationships among tables in the database and preventusers or applications from entering data inconsistent with those rules.Referential integrity rules for example may specify that whenever a useror application deletes a record from Table A, any records in Table Bthat are linked to the deleted record must also be deleted or the recordin Table A cannot be deleted. Referential integrity rules may alsospecify for example that whenever you modify the value of a linked fieldin Table A, all records in Table B that are linked to the field willalso be modified accordingly.

For further explanation of losslessly joining tables to create a knownlossless join by using referential integrity constraints, consider thefollowing example of a join between an employees table and a zip codetable. The employees table includes records for employees uniquelyidentified by a social security number. The employees table is linked toa zip code table through a zip code column in the employees table whichincludes a residential zip code for each employee. Each record in theemployee table has one and only one zip code for each employee. Arelated zip code table includes a zip code column, as well as anothercolumn associating a city with each zip code. Referential integrityconstraints in the example dictate that only one zip code may bedesignated as the residential zip code for an employee. Referentialintegrity constrains in this example also dictate that for each zip codein the employees table one record and only one record exists in the zipcode table. An exemplary join between the employees table and the zipcode table designed to return for each employee a residential city islossless because referential integrity constraints for zip code dictatethat one and only one record from the zip code table is returned foreach employee in the employee table.

For even further explanation of losslessly joining (402) the table (314)that is not invoked by the query to the query to create a known losslessjoin (404) for use in determining whether a selected join in the MQT islossless, FIG. 5 sets forth a flow chart illustrating an exemplarymethod for losslessly joining the table (314) that is not invoked by thequery to the query (304). The method of FIG. 5 includes identifying(502) a primary key (504) in the table (314) not invoked by the query.Identifying (502) a primary key (504) in the table (314) not invoked bythe query is carried out by identifying from the join predicate (313)the primary key of the table not invoked by the query. A primary key ofa table in a relational database uniquely identifies each record in thetable. The primary key can either be a normal attribute that isguaranteed to be unique (such as the social security number in theexemplary employees table above or it can be generated by a databasemanagement system issuing a globally unique identifier for the record.Identifying (502) a primary key (504) in the table (314) not invoked bythe query may be carried out by querying the database management systemfor the primary key.

The method of FIG. 5 also includes identifying (506) a foreign key (508)in the table (316) that is invoked by the query and identifying (510)the same foreign key (512) in the query (304). Identifying (506) aforeign key (508) in the table (316) that is invoked by the query (502)may be carried out by identifying from the join predicate (313) theforeign key of the table that is invoked by the query. A foreign key isa field in a relational table that matches the primary key column ofanother table. The foreign key is often used to cross-reference tables.Identifying (506) a foreign key (508) in the table (316) of the MQT andidentifying (510) the same foreign key (512) in the query (304) may becarried out by searching the table in the MQT for a foreign key matchingthe table of the query.

The method of FIG. 5 includes creating (518) a copy (520) of the query(304) and losslessly (514) joining the primary key (504) to the sameforeign key (512) of the copy (520) of the query (304). Creating a copyof the query advantageously provides a disposable form of the query foruse in carrying out the steps of query expansion for materialized querytable matching according to embodiments of the present invention.

For even further explanation, consider the following example of MQTmatching according to the present invention to expand this query:

-   -   Query

SELECT e.name empname FROM employees e WHERE e.name LIKE ‘A%’

To match this MQT:

MQT SELECT e.name empname, d.name deptname FROM employees e, departmentsd WHERE e.dept=d.id

MQT matching according to this example proceeds by selecting a join inthe materialized query table between a table that is not invoked by thequery and a table that is invoked in the query. In this example, suchjoin is between the departments table and the employees table.

MQT matching according to this example proceeds by identifying from thejoin predicate a primary key in the table not invoked by the query. Inthis example, the primary key is the ID column of the departments table.

MQT matching according to this example proceeds by identifying from thejoin predicate a foreign key in the table that is invoked by the query.In this example the foreign table is the employees table and the foreignkey is the department column of the foreign table.

MQT matching according to this example proceeds by identifying the sameforeign key in the query. In this example, the same foreign table is theemployees table and the foreign key is also the department column of theforeign table.

MQT matching according to this example proceeds by losslessly joiningthe primary key of the table not invoked by the query to the sameforeign key in the query. In this example, losslessly joining theprimary key of the table not invoked by the query to the same foreignkey in the query is carried out by creating a join predicate thatimplements a lossless join between the existing foreign table(employees) and the new primary table (departments). In this example thefollowing join predicate e.dept=dept.id implements a lossless join.

MQT matching according to this example proceeds by determining whetherthe lossless join to the query matches the selected join of thematerialized query table. In this example, the known lossless joinexpanded to the query using the predicate e.dept=dept.id now matches thejoin in the MQT. The join in the MQT is therefore lossless and the MQTmay be useful in satisfying the query.

MQT matching according to this example proceeds by repeating the stepsabove for all joins in the MQT until all unmatched tables in the MQThave new matches created in the query.

Exemplary embodiments of the present invention are described largely inthe context of a fully functional computer system for materialized querytable matching. Readers of skill in the art will recognize, however,that the present invention also may be embodied in a computer programproduct disposed on signal bearing media for use with any suitable dataprocessing system. Such signal bearing media may be transmission mediaor recordable media for machine-readable information, including magneticmedia, optical media, or other suitable media. Examples of recordablemedia include magnetic disks in hard drives or diskettes, compact disksfor optical drives, magnetic tape, and others as will occur to those ofskill in the art. Examples of transmission media include telephonenetworks for voice communications and digital data communicationsnetworks such as, for example, Ethernets™ and networks that communicatewith the Internet Protocol and the World Wide Web. Persons skilled inthe art will immediately recognize that any computer system havingsuitable programming means will be capable of executing the steps of themethod of the invention as embodied in a program product. Personsskilled in the art will recognize immediately that, although most of theexemplary embodiments described in this specification are oriented tosoftware installed and executing on computer hardware, nevertheless,alternative embodiments implemented as firmware or as hardware are wellwithin the scope of the present invention.

It will be understood from the foregoing description that modificationsand changes may be made in various embodiments of the present inventionwithout departing from its true spirit. The descriptions in thisspecification are for purposes of illustration only and are not to beconstrued in a limiting sense. The scope of the present invention islimited only by the language of the following claims.

1-6. (canceled)
 7. An apparatus for materialized query table matching,the apparatus comprising: a computer processor; a computer memorycoupled for data transfer to the processor, the computer memory havingdisposed within it computer program instructions comprising: a databasemanagement system; the database management system capable of: receivinga database query; retrieving a materialized query table from datastorage accessible to a database management system; selecting a join inthe materialized query table between a table that is not invoked by thequery and a table that is invoked in the query; determining whether theselected join is lossless including: losslessly joining the table thatis not invoked by the query to the query including: identifying aprimary key in the table not invoked by the query; identifying a foreignkey in the table that is invoked by the query; identifying the sameforeign key in the query; losslessly joining the primary key of thetable not invoked by the query to the same foreign key in the queryincluding:  creating a copy of the query;  losslessly joining theprimary key to the same foreign key of the copy of the query;determining whether the lossless join to the query matches the selectedjoin of the materialized query table; and if the selected join islossless, expanding the query to include the lossless join. 8.(canceled)
 9. (canceled)
 10. (canceled)
 11. (canceled)
 12. The apparatusof claim 7 wherein the database management system is further capable ofdetermining whether all the joins in the materialized query table havebeen selected; and selecting another materialized query table if all thejoins in the materialized query table have been selected.
 13. A computerprogram product for materialized query table matching, the computerprogram product disposed upon a recordable medium, the computer programproduct comprising: computer program instructions that receive adatabase query; computer program instructions that retrieve amaterialized query table from data storage accessible to a databasemanagement system; computer program instructions that select a join inthe materialized query table between a table that is not invoked by thequery and a table that is invoked in the query; computer programinstructions that determine whether the selected join is losslessincluding: computer program instructions that losslessly join the tablethat is not invoked by the query to the query including: computerprogram instructions that identify a primary key in the table notinvoked by the query; computer program instructions that identify aforeign key in the table that is invoked by the query; computer programinstructions that identify the same foreign key in the query; computerprogram instructions that losslessly join the primary key of the tablenot invoked by the query to the same foreign key in the query including:computer program instructions that create a copy of the query; computerprogram instructions that losslessly join the primary key to the sameforeign key of the copy of the query; computer program instructions thatdetermine whether the lossless join to the query matches the selectedjoin of the materialized query table; and computer program instructionsthat expand the query to include the lossless join if the selected joinis lossless.
 14. (canceled)
 15. (canceled)
 16. (canceled)
 17. (canceled)18. (canceled)
 19. (canceled)
 20. The method of claim 13 furthercomprising computer program instructions that determine whether all thejoins in the materialized query table have been selected; and computerprogram instructions that select another materialized query table if allthe joins in the materialized query table have been selected.